home *** CD-ROM | disk | FTP | other *** search
/ Deutsche Edition 1 / Deutsche Edition 1.iso / amok / 031-040 / amok32 / tasksupport / tasksupport.dok < prev    next >
Text File  |  1993-11-04  |  8KB  |  179 lines
  1. ======================================================================
  2. Dokumentation zu "TaskSupport" Version 1.1
  3. Autor: Nicolas Benezan, Postwiesenstr. 2, D7000 Stuttgart 60
  4. ======================================================================
  5.  
  6. Übersicht
  7. ­­­­­­­­­
  8. * Kopierrecht
  9. * Umfang des Projekts
  10. * Einleitung
  11. * Beschreibung der Prozeduren
  12. * Demo- / Testprogramm
  13.  
  14.  
  15. Kopierrecht
  16. ­­­­­­­­­­­
  17. Das komplette Projekt (Quelltext, Dokumentation und Objectcode) ist
  18. Public Domain Software. Es darf beliebig kopiert und verbreitet werden
  19. solange...
  20.  
  21. * mein Name und dieser Kopierrechtshinweis erhalten bleiben,
  22. * die Vollständigkeit des ganzen Projekts gewährleistet ist, und
  23. * mit dem Vertrieb dieser Software kein Gewinn erwirtschaftet wird.
  24.  
  25. Die Kommerzielle Nutzung ohne meine ausdrückliche schriftliche
  26. Genehmigung ist untersagt (über Gewinnbeteiligung läßt sich reden).
  27. W i c h t i g: Dies gilt insbesondere auch für "schwarze Schafe" der
  28. "PD"-Versandhäuser, die ganz offensichtlich Gewinn machen, was z.B. durch
  29. ganzseitige Anzeigen in Zeitschiften erkennbar ist.
  30.  
  31. Verbesserungsvorschläge sind stets willkommen. Falls Sie Veränderungen
  32. am Programm vornehmen, dokumentieren Sie diese bitte gut verständlich.
  33. Es würde mich freuen, wenn Sie mich über größere Veränderungen oder
  34. Erweiterungen in Kenntnis setzen würden.
  35.  
  36. (c) 1988 by Nicolas Benezan.
  37.  
  38. --------------------------------------------------------------------------
  39. Ich möchte an dieser Stelle Bernd Preusing danken, der mir bei der
  40. Realisierung dieses Moduls sehr geholfen hat.
  41. --------------------------------------------------------------------------
  42.  
  43.  
  44. Umfang des Projekts
  45. ­­­­­­­­­­­­­­­­­­­
  46. Das komplette Projekt "TaskSupport" beinhaltet folgende Dateien:
  47.  
  48. * TaskSupport.dok       Diese Dokumentation
  49. * TaskSupport.def       Definitionsmodul
  50. * TaskSupport.mod       Implementationsmodul
  51.  
  52. (Stand 12.Jan.1990)
  53.  
  54.  
  55. Einleitung
  56. ­­­­­­­­­­
  57. Die Programmierung von eigenen Tasks führt aufgrund der folgenden
  58. Schwierigkeiten leider oft zu Guru-Meditations:
  59.  
  60. * ExecSupport.CreateTask (zumindest ältere Versionen) haben einen Bug: sie
  61.   stürzen, wenn nicht mehr genügend Speicher vorhanden ist. Dies liegt an
  62.   der Dummheit von Exec.AllocEntry, das einen Fehler nicht durch NIL
  63.   sondern durch Bit 31 anzeigt, übrigens entgegen der Konvention, die
  64.   oberen 8 Bit einer Adresse nicht für Daten zu benutzen.
  65.  
  66. * Das Stack-Checking von Modula verwendet dummerweise nicht das Feld
  67.   Task^.spLower sondern eine eigene Variable Arts.stackTop. Hat das
  68.   Programm mehrere Tasks, dann ist diese natürlich normalerweise nicht
  69.   immer richtig gesetzt. Entweder man schaltet das Stack-Checking ganz ab,
  70.   oder man hofft auf den Zufall, daß der Stack des neuen Tasks an einer
  71.   höheren Adresse liegt als der des Haupttasks. Beides sehr unbefriedigende
  72.   Lösungen.
  73.  
  74. * Das Problem der korrekten Terminierung: Da jeder Task, der Teile des
  75.   gleichen Code-Segments benutzt wie das Hauptprogramm, spätestens dann
  76.   terminieren muß, wenn es das Hauptprogramm tut, muß jeder neu erzeugte
  77.   Task (ohne eigenes Code-Segment) auch irgendwann wieder gelöscht werden.
  78.   Es reicht jedoch nicht, einfach ein Exec.RemTask() oder ExecSupport.-
  79.   DeleteTask() in eine TermProcedure zu schreiben, den ohne besondere
  80.   Vorkehrungen wäre es auch möglich, daß der Task schon vorher terminierte,
  81.   und einen Task löschen den es nicht gibt...
  82.   Es ist übrigens auch keine Lösung, vorher mit FindTask nachzuschauen,
  83.   ob der Task noch existiert. Was ist, wenn man das Programm zweimal
  84.   startet, also dann existieren zwei Tasks mit gleichem Namen. Wenn jetzt
  85.   das eine Programm den Task des anderen findet und denkt SEIN task wäre
  86.   noch da, und diesen irrtümlicherweise löscht... nu ja, hallo Guru!
  87.  
  88. * Selbsterzeugte Tasks können normalerweise keine Dos-Prozeduren verwenden,
  89.   da ihnen die Process-Struktur fehlt (Das ist das, wo der ganze BCPL-Kram
  90.   drinsteht, unter anderem CurrentDir und verschiedenes fürs File-System).
  91.   Dos.CreateProc() anstelle von ExecSupport.CreateTask() hilft da auch
  92.   nicht, da es sehr schlecht dokumentiert und daher sehr schwierig
  93.   einzusetzten ist (es gelang mir auch nach längerem Experimentieren nicht,
  94.   einen Prozess zu erzeugen und wieder zu löschen, ohne daß jedesmal 24
  95.   Bytes geschluckt wurden).
  96.  
  97. * Es giebt immer wieder fehlerhafte Multitasking-Programme, die die
  98.   Prinzipien des gegenseitigen Ausschlusses (Forbid, Semaphoren) nicht
  99.   beachten, gegen Deadlocks nicht ausreichend vorbeugen oder ihre Resourcen
  100.   nicht mehr zurückgeben. Leider ist das Amiga-Betriebssystem hierbei sehr
  101.   ungnädig, der Programmierer hat die volle Verantwortung.
  102.  
  103. Mit dem Modul "TaskSupport" werden diese Fallen so weit wie es geht
  104. umgangen. Es stellt Prozeduren zum Erzeugen und Löschen von Tasks
  105. (bzw. Dos-Prozessen) zur Verfügung, die ein großes Maß an Absturzsicherheit
  106. besitzen. Natürlich ist gegen den letzten Punkt kein Kraut gewachsen, da
  107. muß jeder selbst aufpassen.
  108.  
  109.  
  110. Beschreibung der Prozeduren
  111. ­­­­­­­­­­­­­­­­­­­­­­­­­­­
  112.  
  113. CreateTask
  114. ----------
  115. Diese Prozedur diest zum Erzeugen und Starten eines neuen Tasks. Außer der
  116. Prozedur, die als Task gestartet werden soll, müssen noch ein Name, die
  117. Größe des Stacks und die Priorität angegeben werden.
  118.  
  119. Der Name ist für System-Debugger-Tools ganz nützlich. Aus ihm sollte
  120. ersichtlich sein, zu welchem Programm der Task gehört, und falls es
  121. meherere gibt, was er macht. Forsicht mit Exec.FindTask(). Sie können zwar
  122. nach Tasks mit bestimmtem Namen suchen, rechnen Sie jedoch damit, daß es
  123. mehrere Tasks mit gleichem Namen gibt. Wenn sie eindeutige Namen benötigen,
  124. Verwenden Sie die Systemzeit zusammen mit Ihrem Programmnamen (z.B.
  125. "TaskTest.SSSSSS.MMMMM", wobei S und M für "secs" und "micro" eines
  126. "Timer.TimeVal"s stehen).
  127.  
  128. Die erforderliche Stackgröße hängt von der Tiefe der Prozedurverschach-
  129. telung oder Rekursion ab. 1k ist Minimum, 4k Standard und 20k sollten auf
  130. jeden Fall reichen. Das Stack-Checking darf (sollte auch) eingeschaltet
  131. bleiben. Durch einen Trick (Launch/Switch-Prozeduren) wird sichergestellt,
  132. daß Arts.stackTop immer richtig gesetzt ist.
  133.  
  134. Gehen Sie vorsichtig mit der Priorität um! geben Sie nur solchen Tasks eine
  135. Priorität > 0, die relativ sparsam mit der Rechenzeit umgehen (oft warten,
  136. aber schnell reagieren müssen), sonst wird das System blockiert.
  137.  
  138. Der Parameter "InitArg" ist eine spezielle Zugabe von TaskSupport. Es ist
  139. möglich, dem neuen Task ein Argument (z.B. Zeiger auf ein RECORD) zu
  140. übergeben (Parameter von TaskProc). Das ist besonders dann nützlich, wenn
  141. dieselbe Prozedur mehrmals als Task gestartet wird, aber jedesmal auf
  142. andere Daten wirken soll. In diesem Fall können nämlich keine globalen
  143. Variablen zur Parameterübergabe verwendet werden.
  144.  
  145. Der neue Task erhält auch eine Dos.Process-Struktur, sodaß er auch
  146. Dos-Prozeduren verwenden darf. Es sollte jedoch beachtet werden, daß sein
  147. CurrentDir am Anfang auf NIL steht, also erst noch initialisiert werden
  148. sollte. Wenn Sie dafür einen neuen FileLock Dos.Lock()en, achten Sie
  149. darauf, ihn vor Beendigung des Tasks wieder zu UnLock()en.
  150.  
  151. Wenn der neu gestartete Task Speicher alloziert, sollten Sie am besten
  152. das Modul "TaskMemory" oder "MemSystem" benutzen. Es ist damit
  153. sichergestellt, daß der Speicher bei Beendigung des Tasks freigegeben wird
  154. (Vorsicht: stellen Sie sicher, das andere Tasks nicht mehr auf solchen
  155. freigegebenen Speicher zugreifen!).
  156.  
  157. DeleteTask
  158. ----------
  159. Diese Prozedur bricht einen Task ab, entfernt den Task selbst und gibt
  160. allen Speicher frei, den er (mit "TaskMemory" oder "MemSystem") alloziert
  161. hat.
  162.  
  163. Es ist erlaubt, daß ein Task sich selbst löscht.
  164.  
  165. Existiert ein Task, der gelöscht werden soll, nicht mehr, wird der Aufruf
  166. einfach ignoriert. Es ist auch nicht möglich, den Haupt-Task oder einen
  167. Task, der nicht zum Programm gehört (der nicht mit TaskSupport.CreateTask
  168. erzeugt wurde), zu löschen.
  169.  
  170. Wird das Hauptprogramm beendet, werden alle noch existierenden Tasks
  171. automatisch gelöscht.
  172.  
  173.  
  174. Demo- / Testprogramm
  175. ­­­­­­­­­­­­­­­­­­­­
  176. Ein Demoprogramm ist im Projekt "RingBuffers" enthalten (auch auf dieser
  177. Diskette).
  178.  
  179.